自從這幾年DevOps不知怎地流行起來後，關於自動化部署這件事情，討論度一下子變得很高。贊成跟反對的聲音都有，不過，有些反對的聲音，聽起來很合理，好像沒什麼能反駁的，但是事實上都有其問題存在。我認為，世界上的經驗有千千百百種，但是邏輯只有一種。抓住邏輯，就能做出萬種應變。以下我們只簡單列出幾項常見的論述，並推敲一下其邏輯上的謬誤：

自動化部署不完全，做不了全套。

有人認為，自己寫的自動化部署腳本，無法達成所有我們在部署過程中需要執行的步驟。譬如，我自動化地上傳了binary，如jar檔，但是用戶狀態我還是得手動更新；或是我自動化地關閉與開啟了服務，但是簡訊通知客戶，我還是得電話或line通知客服等。

事實上，這樣的想法，等於是把自動化部署，侷限在了單一工具的使用，或是單一任務的執行。其實，技術上，只要是人能靠打指令做到的事，機器都可以幫忙做。譬如，上述的例子，就可以透過maven、ssh、SQLPlus、Line Robot API的協動來完成，並且利用ansible來控制這些工具在本地及遠端伺服器的動作。

所以不是自動化部署做不了整套，而是你的腳本還沒做到整套。

臨時狀況時，機器會做錯事。

如果我把部署動作拆解成： 1) 停止服務， 2) 上傳jar檔， 3) 更新設定檔與靜態資源， 與 4) 重啟服務。
很多人會擔心，設計一套固定腳本，萬一上傳jar檔卡住了，或是靜態資源沒更新完就終止，接著服務就傻傻地被開啟，那用戶不就會使用到錯誤的參數，得到錯誤的結果了嗎？那我還不如手動一步一步做，雖然慢了一點，但是我可以每做一步就停下來檢查，不是更安全？

非也，非也。

我同意『每做一步就停下來檢查』這件事，這件事在確保正確性方面，實屬有益無害。然而，人能做的檢查，機器就不能做嗎？真的不能嗎？我們舉個例子：我今天要修改服務設定檔，要把某個服務的port從3333改成7777，於是我必須要在開啟服務之前，檢查每台伺服器的該檔案的該值是否已被更新成7777，一但有任何一台有誤，我就馬上停下來修正，直到所有檢查都完成了才開啟服務。

如果你只有2台server，那妳可以一台一台ssh進去看，萬一你的伺服器有5台，或是10台，甚至20台呢？首先，ssh去檢查這件事，都不用靠任何先進工具，光靠一個shell script就能做到，更何況現在已經有諸多工具，能夠平行地上傳並檢查md5或是檔案內容，一旦有錯還能自動回朔到上一版本，而這版本也是自動記錄的，不用另外手抄。你說，到底是手動安全還是自動安全？邏輯搞通了沒？還沒？我們再看看這個：

環境變化快時，腳本不易維護

環境變化快時，需求也變得快。腳本會比較不易維護，這倒是真的。但是這個『不易維護』的現象，在邏輯上，到底是相對於誰而言？是比需求變化慢時不易維護呢，還是比手動佈署還不易維護呢？

沒有正確的對比目標，這樣的立論是不科學的。

但是，修改腳本只要存檔後，第二次的執行步驟就不會錯，除非你再因應需求再更改。反觀改變習慣呢？人的習慣一旦養成了，就很難很快改過來。再有經驗的工程師，都難逃習慣的影響。也許，他出錯率比別人低一些，但是，在環境變化快速時，你認為長久以來的習慣會不會造成若干程度的影響？

腳本不易維護是沒錯，但是養成習慣的潛意識動作難道就比較容易維護？你認為呢？

我們這麼說吧：

你的同業檢查100台機器的30個設定檔只要30秒，你需要幾秒？
你的同業上傳100台機器的jar檔只要30秒，你需要幾秒？
你的同業買了新機器並做完基礎設定後，佈署成特定版本的特定服務只要3分鐘，你需要幾分鐘？
你的同業在線上發生重大缺失時，把100台server上的服務都退回前一版本只要5分鐘，你需要幾分鐘？

回應前面說的，世界上的經驗有千千百百種，但是邏輯只有一種。找出經驗中正確的邏輯，套用在未來的事件，變成更好的經驗；找出經驗中錯誤的邏輯，加以修正，避免未來類似事件中重複同樣的錯誤，才是我們學習科學的實用之處。